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Abstract 


This document examines the applicability of using existing GMPLS routing and signaling 
mechanisms to set up Optical Data Unit-k (ODUk) Label Switched Paths (LSPs) over Optical Data 
Unit-Cn (ODUCn) links as defined in the 2020 version of ITU-T Recommendation G.709. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is published for informational 
purposes. 


This document is a product of the Internet Engineering Task Force (IETF). It represents the 
consensus of the IETF community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Not all documents approved by 
the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 
on it may be obtained at https://www.rfc-editor.org/info/rfc9376. 


Copyright Notice 


Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights 
reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 
Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this 
document. Please review these documents carefully, as they describe your rights and restrictions 
with respect to this document. Code Components extracted from this document must include 
Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are 
provided without warranty as described in the Revised BSD License. 


Wang, et al. Informational Page 1 


RFC 9376 Applicability of GMPLS beyond 100 Gbit/s OTN 


Table of Contents 


1. Introduction 
2. OTN Terminology Used in This Document 
3. Overview of OTUCn/ODUCn in G.709 
3.1. OTUCn 
3.1.1. OTUCn-M 


3.2. ODUCn 
3.3. Tributary Slot Granularity 
3.4. Structure of OPUCn MSI with Payload Type 0x22 


3.5. Client Signal Mappings 


4. GMPLS Implications and Applicability 
4.1. TE Link Representation 
4.2. GMPLS Signaling 
4.3. GMPLS Routing 


5. IANA Considerations 
6. Security Considerations 
7. References 
7.1. Normative References 


7.2. Informative References 


Appendix A. Possible Future Work 
Contributors 


Authors' Addresses 


1. Introduction 


March 2023 


The current GMPLS routing [RFC7138] and signaling [RFC7139] extensions support the control of 
the Optical Transport Network (OTN) signals and capabilities that were defined in the 2012 


version of ITU-T Recommendation G.709 [ITU-T_G709_2012]. 
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In 2016, a new version of ITU-T Recommendation G.709 was published: [ITU-T_G709_2016]. This 
version introduced higher-rate Optical Transport Unit (OTU) and Optical Data Unit (ODU) signals, 
termed "OTUCn" and "ODUCn", respectively, which have a nominal rate of n*100 Gbit/s. 
According to the definition in [ITU-T_G709_2016], OTUCn and ODUCn perform only the digital 
section-layer role, and ODUCn supports only ODUk clients. This document focuses on the use of 
existing GMPLS mechanisms to set up ODUk (e.g., ODUflex) Label Switched Paths (LSPs) over 
ODUCn links, independently from how these links have been set up. 


Because [ITU-T_G709_2020] does not introduce any new features to OTUCn and ODUCn compared 
to [ITU-T_G709_2016], this document first presents an overview of the OTUCn and ODUCn signals 
in [ITU-T_G709_2020] and then analyzes how the current GMPLS routing and signaling 
mechanisms can be utilized to set up ODUkK (e.g., ODUflex) LSPs over ODUCn links. 


This document assumes that readers are familiar with OTN, GMPLS, and how GMPLS is applied 
in OTN. As such, this document doesn't provide any background pertaining to OTN that include 
links with capacities of 100 Gbit/s or less; this background could be found in documents such as 
[RFC7062] and [RFC7096]. This document provides an overview of the data plane primitives that 
enable links with capacities greater than 100 Gbit/s and analyzes the extensions that would be 
required in the current GMPLS routing and signaling mechanisms to support evolution in OTN. 


2. OTN Terminology Used in This Document 


FlexO: Flexible OTN information structure. This information structure usually has a specific 
bitrate and frame format that consists of overhead and payload, which are used as a group for 
the transport of an OTUCn signal. 


LSP: Label Switched Path 


MSI: Multiplex Structure Indicator. This structure indicates the grouping of the tributary slots 
in an OPU payload area that realizes a client signal, which is multiplexed into an OPU. The 
individual clients multiplexed into the OPU payload area are distinguished by the Tributary 
Port Number (TPN). 


ODU: Optical Data Unit. An ODU has the frame structure and overhead, as defined in Figure 
12-1 of [ITU-T_G709_2020]. ODUs can be formed in two ways: a) by encapsulating a single non- 
OTN client, such as SONET/SDH (Synchronous Optical Network / Synchronous Digital 
Hierarchy) or Ethernet, or b) by multiplexing lower-rate ODUs. In general, the ODU layer 
represents the path layer in OTN. The only exception is the ODUCn signal (defined below), 
which is defined to be a section-layer signal. In the classification based on bitrates of the ODU 
signals, ODUs are of two types: fixed rate and flexible rate. Flexible-rate ODUs, called 
"ODUflex", have a rate that is 239/238 times the bitrate of the client signal they encapsulate. 


ODUC: Optical Data Unit-C. This signal has a bandwidth of approximately 100 Gbit/s and is of a 
slightly higher bitrate than the fixed rate ODU4 signal. This signal has the format defined in 
Figure 12-1 of [ITU-T_G709_2020]. This signal represents the building block for constructing a 
higher-rate signal called "ODUCn" (defined below). 
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ODUCn: Optical Data Unit-Cn, where Cn indicates the bitrate of approximately n*100 Gbit/s. 
This frame structure consists of "n" interleaved frame and multiframe synchronous instances 
of the ODUC signal, each of which has the format defined in Figure 12-1 of [ITU-T_G709_2020]. 


ODUflex: Optical Data Unit - flexible rate. An ODUflex has the same frame structure as a 
"generic" ODU but with a rate that is a fixed multiple of the bitrate of the client signal it 
encapsulates. [ITU-T_G709_2020] defines specific ODUflex containers that are required to 
transport specific clients such as 50GE, 200GE, 400GE, etc. 


ODUk: Optical Data Unit-k, where kis one of {0, 1, 2, 2e, 3, 4}. The term "ODUk" refers to an ODU 
whose bitrate is fully specified by the index k. The bitrates of the ODUk signal for k = {0, 1, 2, 
2e, 3, 4} are approximately 1.25 Gbit/s, 2.5 Gbit/s, 10 Gbit/s, 10.3 Gbit/s, 40 Gbit/s, and 100 Gbit/ 
s, respectively. 


OPUC: Optical Payload Unit-C. This signal has a payload of approximately 100 Gbit/s. This 
structure represents the payload area of the ODUC signal. 


OPUCn: Optical Payload Unit-Cn, where Cn indicates that the bitrate is approximately n*100 
Gbit/s. This structure represents the payload area of the ODUCn signal. 


OTN: Optical Transport Network 


OTUC: Optical Transport Unit-C. This signal has a bandwidth of approximately 100 Gbit/s. This 
signal forms the building block of the OTUCn signal defined below, which has a bandwidth of 
approximately n*100 Gbit/s. 


OTUCn: Fully standardized Optical Transport Unit-Cn. This frame structure is realized by 
extending the ODUCn signal with the OTU layer overhead. The structure of this signal is 
illustrated in Figure 11-4 of [ITU-T_G709_2020]. Note that the term "fully standardized" is 
defined by ITU-T in Section 6.1.1 of [ITU-T_G709_2020]. 


OTUCn-M: This signal is an extension of the OTUCn signal introduced above. This signal 
contains the same amount of overhead as the OTUCn signal but contains a reduced amount of 
payload area. Specifically, the payload area consists of M tributary slots (each 5 Gbit/s), where 
M is less than 20*n, which is the number of tributary slots in the OTUCn signal. 


PSI: Payload Structure Indicator. This is a 256-byte signal that describes the composition of the 
OPU signal. This field is a concatenation of the payload type (PT) and the Multiplex Structure 
Indicator (MSD defined below. 


TPN: Tributary Port Number. The tributary port number is used to indicate the port number of 
the client signal that is being transported in one specific tributary slot. 


Detailed descriptions for some of these terms can be found in [ITU-T_G709_2020]. 
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3. Overview of OTUCn/ODUCn in G.709 


This section provides an overview of the OTUCn/ODUCn signals defined in [ITU-T_G709_ 2020]. 
The text in this section is purely descriptive and is not normative. For a full description of 
OTUCn/ODUCn signals, please refer to [ITU-T_G709_2020]. In the event of any discrepancy 
between this text and [ITU-T_G709_2020], that other document is definitive. 


3.1. OTUCn 


In order to carry client signals with rates greater than 100 Gbit/s, [ITU-T_G709_2020] takes a 
general and scalable approach that decouples the rates of OTU signals from the client rate. The 
new OTU signal is called "OTUCn", and this signal is defined to have a rate of (approximately) 
n*100 Gbit/s. The following are the key characteristics of the OTUCn signal: 


e The OTUCn signal contains one ODUCn. The OTUCn and ODUCn signals perform digital 
section-layer roles only (see Section 6.1.1 of [ITU-T_G709_2020]) 

e The OTUCn signals are formed by interleaving n synchronous OTUC signals (which are 
labeled 1, 2, ..., n). 

e Each of the OTUC instances has the same overhead as the standard OTUk signal in [ITU- 
T_G709_2020]. Note that the OTUC signal doesn't include the Forward Error Correction (FEC) 
columns illustrated in Figure 11-1 of [ITU-T_G709_2020]. The OTUC signal includes an ODUC. 

e The OTUC signal has a slightly higher rate compared to the OTU4 signal (without FEC); this is 
to ensure that the OPUC payload area can carry an ODU4 signal. 

e The combined signal OTUCn has n instances of OTUC overhead and n instances of ODUC 
overhead. 


The OTUCn, ODUCn, and OPUCn signal structures are presented in a (physical) interface- 
independent manner, by means of n OTUC, ODUC, and OPUC instances that are marked #1 to #n. 


OTUCn interfaces can be categorized as follows, based on the type of peer network element: 


inter-domain interfaces: These types of interfaces are used for connecting OTN edge nodes to 
(a) client equipment (e.g., routers) or (b) hand-off points from other OTN. ITU-T 
Recommendation G709.1 [ITU-T_G709.1] specifies a flexible interoperable short-reach OTN 
interface over which an OTUCn (n >=1) is transferred, using bonded Flexible OTN information 
structure (FlexO) interfaces, which belong to a FlexO group. 


intra-domain interfaces: In these cases, the OTUCn is transported using a proprietary (vendor- 
specific) encapsulation, FEC, etc. It is also possible to transport OTUCn for intra-domain links 
using FlexO. 
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3.1.1. OTUCn-M 


The standard OTUCn signal has the same rate as the ODUCn signal. This implies that the OTUCn 
signal can only be transported over wavelength groups that have a total capacity of multiples of 
(approximately) 100 Gbit/s. Modern optical interfaces support a variety of bitrates per 
wavelength, depending on the reach requirements for the optical path. If the total rate of the 
ODUk LSPs planned to be carried over an ODUCn link is smaller than n*100 Gbit/s, it is possible 
to "crunch" the OTUCn, and the unused tributary slots are thus not transmitted. [ITU- 
T_G709_2020] supports the notion of a reduced-rate OTUCn signal, termed "OTUCn-M". The 
OTUCn-M signal is derived from the OTUCn signal by retaining all the n instances of overhead 
(one per OTUC instance) but with only M (M is less than 20*n) OPUCn tributary slots available to 
carry ODUk LSPs. 


3.2. ODUCn 


The ODUCn signal defined in [ITU-T_G709_2020] can be viewed as being formed by the 
appropriate interleaving of content from n ODUC signal instances. The ODUC frames have the 
same structure as a standard ODU in the sense that the frames have the same overhead and 
payload areas but have a higher rate since their payload area can embed an ODU4 signal. 


The ODUCn is a multiplex section ODU signal and is mapped into an OTUCn signal, which 
provides the regenerator section layer. In some scenarios, the ODUCn and OTUCn signals will be 
coterminated, i.e., they will have identical source/sink locations (see Figure 1). In Figure 1, the 
term "OTN Switch" has the same meaning as that used in Section 3 of [RFC7138]. [ITU- 
T_G709_2020] allows for the ODUCn signal to pass through one or more digital regenerator nodes 
(shown as nodes B and C in Figure 2), which will terminate the OTUCn layer but will pass the 
regenerated (but otherwise untouched) ODUCn towards a different OTUCn interface where a 
fresh OTUCn layer will be initiated. This process is termed as "ODUCn regeneration" in Section 7.1 
of [ITU-T_G872]. In this example, the ODUCn is carried by three OTUCn segments. 


Specifically, the OPUCn signal flows through these regenerators unchanged. That is, the set of 
client signals, their TPNs, and tributary-slot allocations remains unchanged. 


+-------- + +-------- + 
| St tS + | 
| OTN Ja aa | OTN | 
ESwitehi t oo + Switch | 
| A | | B | 
| AAA MA + | 
+-------- + +-------- + 
A ODUCn------- > 
ua OTUCn------ > 


Figure 1: ODUCn Signal 
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+--------- + +-------- + +-------- + +-------- + 
| +-------- + | | +---------- + | 
| OTN | -------- | OTN | | OTN |---------- | OTN 
| Switch +-------- + Regen +-------- + Regen +---------- + Switch | 
| A | | B | | C | | D | 
| ee + | | a + | 
+--------- + +-------- + +-------- + 4+-------- + 
CS tin iim i itm OD Ca > 
<--------------- ><----------------- ><------------------ > 
OTUCn OTUCn OTUCn 


Figure 2: ODUCn Signal - Multi-Hop 


3.3. Tributary Slot Granularity 


[ITU-T_G709_2012] introduced the support for 1.25 Gbit/s granular tributary slots in OPU2, OPU3, 
and OPU4 signals. [ITU-T_G709_2020] defined the OPUC with a 5 Gbit/s tributary slot granularity. 
This means that the ODUCn signal has 20*n tributary slots (of 5 Gbit/s capacity). The range of 
tributary port number (TPN) is 10*n instead of 20*n, which restricts the maximum client signals 
that could be carried over one single ODUC1. 


3.4. Structure of OPUCn MSI with Payload Type 0x22 


As mentioned above, the OPUCn signal has 20*n tributary slots (TSs) (each 5 Gbit/s). The OPUCn 
MSI field has a fixed length of 40*n bytes and indicates the availability and occupation of each 
TS. Two bytes are used for each of the 20*n tributary slots, and each such information structure 
has the following format (see Section 20.4.1 of [ITU-T_G709_2020)): 


e The TS availability bit indicates if the tributary slot is available or unavailable. 
e The TS occupation bit indicates if the tributary slot is allocated or unallocated. 


e The tributary port number (14 bits) indicates the port number of the client signal that is 
being carried in this specific TS. A flexible assignment of tributary port to tributary slots is 
possible. Numbering of tributary ports is from 1 to 10*n. 


The concatenation of the OPUCn payload type (PT) and the MSI field is carried over the overhead 
byte designated as PSI in Figure 15-6 of [ITU-T_G709_2020]. 


3.5. Client Signal Mappings 


The approach taken by the ITU-T to map non-OTN client signals to the appropriate ODU 
containers is as follows: 


e All client signals are mapped into an ODUj or ODUk (e.g., ODUflex) as specified in Section 17 
of [ITU-T_G709_2020]. 

e The terms "ODUj" and "ODUk" are used in a multiplexing scenario, with ODUj being a low- 
order ODU that is multiplexed into ODUk, a high-order ODU. As Figure 3 illustrates, the 
ODUCn is also a high-order ODU into which other ODUs can be multiplexed. The ODUCn itself 
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cannot be multiplexed into any higher-rate ODU signal; it is defined to be a section-level 
signal. 


e ODUflex signals are low-order signals only. If the ODUflex entities have rates of 100 Gbit/s or 
less, they can be transported over either an ODUk (k=1..4) or an ODUCn. For ODUflex 
connections with rates greater than 100 Gbit/s, ODUCn is required. 

e ODU Virtual Concatenation (VCAT) has been deprecated. This simplifies the network and the 
supporting hardware since multiple different mappings for the same client are no longer 
necessary. Note that legacy implementations that transported sub-100 Gbit/s clients using 
ODU VCAT shall continue to be supported. 


Clients (e.g., SONET/SDH and Ethernet) 


+ 
I 
I 
I 
I 
l] 
I 
I 
I 
I 
I 
I 
I 
I 
I 
I 
I 
+ 
+ — — 


| OPUj | 
| ODUj | 
oe o n naa (SS no oa e a Wa a oe + 
| | 
| OPUk | 
fhe Siena AAA AAA SSeS Ss AAA AAA Se AAA AAA AAA AAA AA + 
| 
| ODUk k in {0,1,2,2e,3,4, flex} | 
ee AAA AAA +----- AAA AAA + 
| | | 
| OTUk, OTUk-SC, OTUk-V | | OPUCn | 
AA AAA AAA AA AA + eta + 
| | 
| ODUCn | 
AUA AAA AAA ZA + 
| | 
| OTUCn | 
AA AA AA AA AAA AAA + 


Figure 3: Digital Structure of OTN Interfaces (from Figure 6-1 of [ITU-T_G709_2020]) 


4. GMPLS Implications and Applicability 


4.1. TE Link Representation 


Section 3 of [RFC7138] describes how to represent G.709 OTUk/ODUk with TE links in GMPLS. In 
the same manner, OTUCn links can also be represented as TE links. Figure 4 provides an 
illustration of a one-hop OTUCn TE link. 
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+---------- + +--------- + 
| OTN | | OTN | 
EE Swi te ha + Switch | 
| A | | B | 
+---------- + +--------- + 
[a OTUCn Link---------- > | 
[a Te olin <a > | 


Figure 4: One-Hop OTUCn TE Link 


It is possible to create TE links that span more than one hop by creating forward adjacencies 
(FAs) between non-adjacent nodes (see Figure 5). In Figure 5, nodes B and C are performing the 
ODUCn regeneration function described in Section 7.1 of [ITU-T_G872] and are not electrically 
switching the ODUCn signal from one interface to another. As in the one-hop case, multi-hop TE 
links advertise the ODU switching capability. 


+-------- + +-------- + +-------- + +--------- + 
| OTN | | OTN | | OTN | | OTN 
| Switch |<------- >| Regen |<-------- >| Regen |<------- >| Switch | 
| A | OTUCn | B | OTUCn | C | OTUCn | OD | 
+-------- enk Ek Se eLink 9 SPSS + 
[RES SS SSS Saas ODUCn Link -------------------- > | 
[SS ele ee We bln ES > | 


Figure 5: Multi-Hop ODUCn TE Link 


The two endpoints of a TE link are configured with the supported resource information (which 
may include whether the TE link is supported by an ODUCn, ODUk, or OTUK), as well as the link 
attribute information (e.g., slot granularity and list of available tributary slot). 


4.2. GMPLS Signaling 


Once the ODUCn TE link is configured, the GMPLS mechanisms defined in [RFC7139] can be 
reused to set up ODUkK/ODUflex LSPs with no changes. As the resource on the ODUCn link that 
can be seen by the ODUk/ODUflex client signal is a set of 5 Gbit/s slots, the label defined in 
[RFC7139] is able to accommodate the requirement of the setup of an ODUk/ODUflex client signal 
over an ODUCn link. In [RFC7139], the OTN-TDM GENERALIZED_LABEL object is used to indicate 
how the lower-order (LO) ODUj signal is multiplexed into the higher-order (HO) ODUk link. In a 
similar manner, the OTN-TDM GENERALIZED_LABEL object is used to indicate how the ODUk 
signal is multiplexed into the ODUCn link. The ODUk signal type is indicated by Traffic 
Parameters. The IF_ID RSVP_HOP object provides a pointer to the interface associated with TE 
link; therefore, the two nodes terminating the TE link know (by internal/local configuration) the 
attributes of the ODUCn TE Link. 
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The TPN defined in [ITU-T_G709_2020] (where it is referred to as "tributary port #") for an ODUCn 
link has 14 bits while this field in [RFC7139] only has 12 bits, so some extension work will 
eventually be needed. Given that a 12-bit TPN field can support ODUCn links with up to n=400 
(i.e., 40 Thit/s links), this need is not urgent. 


The example in Figure 6 illustrates the label format defined in [RFC7139] for multiplexing ODU4 
onto ODUC10. One ODUC10 has 200 slots (each 5 Gbit/s), and twenty of them are allocated to the 
ODU4. With this label encoding, only 20 out of the 200 bits mask are non-zero, which is very 
inefficient. The inefficiency grows for larger values of "n", and an optimized label format may be 


desirable. 


8 1 2 3 
8B1234567890123456078989012345678 961 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| TPN = 3 | Reserved | Length = 200 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
1901101010000000 000000900100000090ƏƏ|İ 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
1@e0000800000000801000018080000001808 88 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
1@00008000000180800000018080000008080 888 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
9000101000000000 000010000010090ƏƏ|İ 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
1@00001000000180000000180008000808 8688 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
1@0000180000001800000008080000010808 88 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

18 880080808 Padding Bits(@) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 6: Label Format 


4.3. GMPLS Routing 


For routing, it is deemed that no extension to the current mechanisms defined in [RFC7138] is 


needed. 


The ODUCn link, which is the lowest layer of the ODU multiplexing hierarchy involving multiple 
ODU layers, is assumed to have been already configured when GMPLS is used to set up ODUk 
over ODUCn; therefore, the resources that need to be advertised are the resources that are 
exposed by this ODUCn link and the ODUk multiplexing hierarchy on it. The 5 Gbit/s OPUCn time 
slots do not need to be advertised, while the 1.25 Gbit/s and 2.5 Gbit/s OPUk time slots need to be 
advertised using the mechanisms already defined in [RFC7138]. 


Since there is a 1:1 correspondence between the ODUCn and the OTUCn signal, there is no need 
to explicitly define a new value to represent the ODUCn signal type in the OSPF-TE routing 


protocol. 
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5. IANA Considerations 


This document has no IANA actions. 


6. Security Considerations 


This document analyzes the applicability of protocol extensions in [RFC7138] and [RFC7139] for 
use in the 2020 version of ITU-T Recommendation G.709 [ITU-T_G709_2020] and finds that no 
new extensions are needed. Therefore, this document introduces no new security considerations 
to the existing signaling and routing protocols beyond those already described in [RFC7138] and 
[RFC7139]. Please refer to [RFC7138] and [RFC7139] for further details of the specific security 
measures. Additionally, [RFC5920] addresses the security aspects that are relevant in the context 
of GMPLS. 
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Appendix A. Possible Future Work 


As noted in Section 4.2, the GMPLS TPN field defined in Section 6.1 of [RFC7139] is only 12 bits, 
whereas an ODUCn link could require up to 14 bits. Although the need is not urgent, future work 
could extend the TPN field in GMPLS to use the Reserved bits immediately adjacent. This would 
need to be done in a backward-compatible way. 


Section 4.2 further notes that the current encoding of GMPLS labels can be inefficient for larger 
values of n in ODUCn. Future work might examine a more compact, yet generalized, label 
encoding to address this issue should it be felt, after analysis of the operational aspects, that the 
current encoding is causing problems. Introduction of a new label encoding would need to be 
done using a new pairing of LSP encoding type and Generalized Payload Identifier (G-PID) to 
ensure correct interoperability. 
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